IBIS Macromodel Task Group Meeting date: 26 September 2017 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to modify his BIRD158.6 draft 7 according to the meeting discussions and send it to Bob R., Mike L., Arpad, and Radek for final review. - Done. - Bob Ross, et. al., to perform final review and editing and post it as BIRD158.6 draft 8. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Radek: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD158.6: - Arpad: I hope we can complete a final review and vote to submit this to the Open Forum. - [sharing draft8 and his email with a few comments/suggestions] - Discussion: Arpad noted some concern about the location of the text explaining that the triangle ground symbols are connected. He felt that its current location under the Tx figure might leave readers thinking it only applied to the Tx. He and Bob noted that Radek had suggested the text could be placed after the entire-channel figure, or after all three figures. Bob and Arpad wondered about the use of the term "Node 0" and if that might be better explained. Arpad, Bob R., Radek, and Mike L., contributed thoughts on the text, and the group arrived at: The triangle ground symbols in the Tx, Rx, and channel circuits represent the same node. This node would typically be the global ground, such as node 0 in IBIS-ISS. Arpad placed this text under each of the 3 figures (Tx, Rx, Channel). Bob noted that at a later date we may want to consolidate into one statement in a single location (instead of 3 copies) as an editorial matter. Arpad noted that he had also wanted to add an explanation of the default value of the optional Rx_R in the paragraph below the Rx figure. He and Radek proposed adding "(default is open circuit)". The group agreed. Arpad noted that he preferred to change "input to the Rx algorithmic model" to "input of the Rx algorithmic model." No one objected. - Arpad: I will save this as draft 9. - Bob: I move to submit this draft9 to the IBIS Open Forum as BIRD158.6. - Walter: Second. [no one opposed] - Arpad: I will send an email to the Open Forum introducing BIRD158.6. IBIS 7.0: - Walter: Now that we have BIRD158, is there anything major left for IBIS 7.0 other than BIRD189? - Michael M.: I don't think so. - My understanding is that the C_comp improvements are not for 7.0? - Walter: That's correct. - Michael M.: In that case, yes, I believe BIRD189 is the last major technical BIRD for IBIS 7.0. BIRD 189: - Walter: I propose we use the rest of this meeting for BIRD 189. - Arpad: I've become concerned about the [Interconnect Model Set] keyword. We can have multiple [Interconnect Model]s inside of it, but we don't have any rules to restrict the way those Models should be written. Someone might provide models that represent multiple options for the same set of pins. Someone else might provide models that provide different portions of the path for given pins (for example buffer to pad in one model and pad to pin in another). In the former situation you might require a selector from the EDA tool so the user can choose a model from the set. In the latter situation you wouldn't, because all of the models in the set have to be used. - When the new [Interconnect Model Set Group] keyword was introduced, I was under the impression that this would be the only thing that would require a selection from the user in case the model maker created multiple groups. But now it occurs to me that inside the [Interconnect Model Set] itself we may still have an ambiguity and may require user selections. - I wonder if we should establish some rules to eliminate the need for selection of Models within a Model Set. - Bob: Yes, I agree. I think we need a rule that no pin name is repeated within an [Interconnect Model Set]. That eliminates the need for any selection of which [Interconnect Model] to use within a Set. I mean that you can't have the same pin repeated at the same interface. (one model could take a particular pin from buffer to pad, and another could take it from pad to pin interface). - Walter: That won't work. If you have crosstalk, you may have a situation where in one Model a particular net is a victim, and in another Model it appears as an aggressor. - Say I have DQ1 through DQ6. - One model may have DQ1, DQ2, and DQ3, where DQ2 is the victim. - Another model may have DQ2, DQ3, DQ4, where DQ3 is the victim. - Maybe you want to give a warning if two Models in the same Set have the same pin as a victim. But that would just be an informative warning. - Bob: To keep it simple put them in two different Sets. - Walter: No, I might have a 64 DQ bus. The model maker might typically extract one swath, say DQ1, DQ2, DQ3, DQ4, DQ5 with DQ3 as the victim. They may then repeat instances of that same s10p for different pins. - Mike L.: What Walter's describing is way of swathing. - Perhaps we could have a rule that no two Models in a Model Set would have exactly the same set of pins? - Arpad: That's the type of rule I'm leaning toward. - If we look at example 4 in the bird189.5_draft9_v1.docx: - There are three different Models for the same pins, but each one is in a separate Model Set. - If we made a rule like this, that would solve this issue. - If we allow these types of repetitions in a Model Set, the user will have to make a choice. - It sounds like Bob and I would like to only have a selector to select from among the Interconnect Model Set Groups. - Walter: I agree with that. - Arpad: If you allow the same pin to appear multiple times as an aggressor in a Model Set, isn't a selection by the user required? - Walter: No, the user knows what victim net they want to simulate. - Bob: There is no requirement that we only simulate victim nets. - You can arbitrarily pick out one pin and simulate that path. - Or you can pick one pin as the agressor and see its effect on all the other pins as victims. - Arpad: I have to think about Walter's crosstalk example more. - I think we have made good progress, and we agree on a preference for one user selection to choose the Group. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Arpad to send BIRD158.6 draft 9 to Mike L. for posting as BIRD158.6. AR: Arpad to send an email to the Open Forum introducing BIRD158.6. AR: Mike L. to post BIRD158.6 ------------- Next meeting: 03 October 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives